The present invention relates generally to the management of Terminate and Stay Resident (TSR) Programs, otherwise known as memory resident programs, written for the MS-DOS or PC-DOS operating systems (DOS TSR) and running in the presence of the Microsoft Windows graphical user interface on an IBM or IBM compatible personal computer, and specifically, to the ability to display to the computer user in the Windows graphical user interface video images depicting dialog boxes which are prompted by a TSR program written for and running in DOS towards soliciting a user response from the user via the Windows graphical user interface and towards communicating that response to the DOS TSR or otherwise performing the requested process commanded by the DOS TSR.
IBM and IBM compatible personal computers introduced in the early 1980's as well as the majority of those computers available to the consuming public today operate using a software platform, or disk operating system, commonly referred to as DOS. The DOS operating system as viewed by the computer user is essentially an interface between the computer user and the computer itself, and is made up of a series of programs which let the computer user communicate with the computer, its data storage media, printers and accessories towards managing programs, data and the hardware elements themselves. One often mentioned shortcoming of the DOS user interface is the fact that it is a purely textual interface in that the user communicates with the computer by entering alpha-numeric commands using a typewriter style keyboard toward instructing the computer to carry out a desired operation. Many of the typewritten textual commands standard to the DOS operating system are mnemonics, abbreviations or "codes" which are cumbersome at best and non-intuitive to the average computer user. In an attempt to overcome the shortcomings of the DOS user interface, Microsoft Corporation has created and markets under the name "WINDOWS" a software program which runs "on top" of the DOS operating system much like any other application program and provides to the computer user a graphical user interface which is thought to provide a more intuitive and efficient user interface than that provided by the original and subsequent versions of the DOS system. Rather than type alpha-numeric commands the user has the option to manipulate a pointer device such as a mouse to position an arrow shaped cursor over a graphical icon depicting a command. By positioning the cursor as described and depressing a button on the mouse the user initiates the command represented by the icon, as opposed to otherwise typing the command on the keyboard. One advantage is the ability to pair icons to specific commands such that the graphical icon bears some connection or resemblance to the nature of the command executed by that icon.
While the DOS and Windows graphical user interfaces may be thought to be "compatible" with one another inasmuch as Windows "runs" on top of DOS, there are fundamental and inherent differences which render computer programs originally written for the DOS operating system incompatible with the Windows graphical user interface. One particular incompatibility which is sought to be remedied by the present invention is the inability of a memory resident program written for the DOS Operating System to generate a visual image which can be displayed to the computer user when the user is running the Windows graphical user interface. The incapability between the DOS and Windows graphical user interfaces relate, in part, to differences between the video modes and processor modes used by each of the two respective interfaces. The nature and generation of the video images displayed to the computer user on the video monitor when running the Windows graphical user interface differ from the images displayed when running the DOS user Interface and give rise to one principle source of incapability. In particular, memory resident programs, as well as general application programs, written for the DOS user Interface do not have access to the Windows graphical user interface, and specifically, the "tools" or "building blocks" which the Windows graphical user interface utilizes in generating the images appearing on the computer monitor. Moreover, memory resident programs for the DOS user Interface cannot by themselves support the video modes used by the Windows graphical user interface. If such DOS TSR's were written so as to provide support for such video modes, the mechanism to provide such support would utilize virtually all available computer memory and thus essentially disable the computer. Moreover, if the user attempts to command a DOS application program to generate images in the conventional manner when the Windows graphical user interface is running, or should a DOS TSR on its own attempt to generate a "DOS" dialog box in the normal DOS manner, the attempt may result in an unrecoverable application error and thus lock-up the computer possibly resulting in the unrecoverable loss of data.
A second basis of incapability is due to the nature of the processor modes utilized by the Windows and DOS Interfaces. The Windows graphical user interface is run only from the protected mode while memory resident programs for the DOS user interface do not function in the protected mode and must use the real mode if they are to operate.
A further distinction is that TSR programs written for the DOS user interface are typically able to easily display a dialog box to the computer user when the computer system is "stable" and in some cases is able to display a dialog box to the user when the system is "unstable" provided that the generation is performed carefully, i.e. without causing conflicts within the system that would result in a crash. During the running of a typical computer application program and the us of conventional DOS commands there are moments in time, however brief, that the computer system may be thought to be unstable due to the computer systems use of certain resources, including memory calls, such that if these resources were sought to be used simultaneously by another program or routine the computer system may "crash", again resulting in a "lock-up" and potential unrecoverable loss of data. For this reason, application program and TSR's are sometimes written such that they exercise certain commands or functions only when the computer system is "stable" and such resources are available.
A typical and useful example of a memory resident program running in the DOS operating system which is helpful in illustrating the operation and utility of the present invention is a Virus Detection Program designed to detect the presence of a computer virus before the virus is loaded into computer memory or otherwise transferred for storage on computer's data storage media, i.e. floppy disk drives, hard disk drives and the like. Typically, a Virus Detection Program operates by intercepting commands issued to either run a designated application program or otherwise open a computer data file. The virus detection program typically operates in a memory resident mode such that commands to run applications or open files may be automatically intercepted on a real time basis without intervention by the computer user. When such a command is issued it is intercepted and the Virus Detection Program becomes active scanning for the presence of a computer virus, typically in the "background" and unnoticed by the computer user. In the event that a computer virus is detected, the virus detection program causes a visual warning to be displayed to the user on the computer monitor in the form of a dialog box informing the user that a virus has been detected and requesting the user's instructions relative to ignoring the detection and proceeding normally or alternatively, blocking execution of the command to run an application or open a file whereby the application is not run and/or the file not opened. Another example of a memory resident program written for the DOS user interface include remote control programs which permit a remotely located computer to take command of the local computer such as when an employee wishes to "operate" his office computer from home in the evening. A memory resident program running on the local computer located at the workplace functions to detect an incoming telephone call initiated by the employee's home computer which when detected launches the remote control program on the workplace computer. Yet a further example of dialog box is its use in requesting the user to enter a password when a restricted command is attempted to be executed. The user would be prompted to enter a password which would in turn be verified by the DOS TSR toward permitting the commanded operation to proceed.
In view of the above described incompatibilities between the DOS and Windows user Interfaces, a Virus Detection Program incorporating a memory resident feature which while properly activated and loaded into the computer memory would nevertheless be incapable of visually notifying the user of the detection of a computer virus due to the inability of the program written for the DOS operating system to generate a visual image compatible with the Windows graphical user interface. Accordingly, the typical prior art memory resident program while being able to function to some extent is unable to interact with the user graphically and is unable to receive a response from the user entered on the computer's keyboard. In such cases the prior art Virus Detection TSR program would either operate without the user's input and assume a worst case scenario thus blocking execution of a program, or rely solely upon the retained ability to generate sound via the computer's speaker inasmuch as the audio path in the typical computer is separate from the Windows graphical user interface.
Accordingly, an object of the present invention is to provide a system to permit a memory resident program written for the DOS interface to communicate with the computer user running the Windows graphical user interface by permitting the display and generation of a dialog box viewable by the user within the Windows graphical user interface.
A further object of the present invention is to provide a system to accept user input in response to the display of a graphical dialog box towards instructing the DOS memory resident program in accordance with the user's direction.
A further object of the present invention is to provide a Management System For Memory Resident Computer Programs which operates in real time and at any time even during system "unstable" periods.
Yet a further object of the present Management System For Memory Resident Computer Programs is to permit a memory resident program written for the DOS user Interface to operate when the Windows Graphical User Interface is in use.
These and other objects of the invention will become apparent in light of the present specifications and drawings.